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REMARKS 

Claims 11-14, 16, 18-19,27-31 and 38-45 are pending in the application. Claim 31 is 
objected to because of an informality. Claims 11 -14, 16, 18-19, 27-31 and 38-45 stand 
rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent No. 6,792,466 to 
Saulpaugh et al. in view of U.S. Patent No. 5,493,692 to Theimer et al. 

Reconsideration is requested. No new matter is added- The rejections are traversed. 
Claims 1 1-14, 16, 18-19, 27-31 and 38-45 remain in the case for consideration. 

REJECTIONS UNDER 35 U.S.C, § 103(a) 
In responding to the Applicant's previous amendment, the Examiner indicated that the 
arguments were not persuasive. The Examiner makes three arguments to support his 
position. First, the Examiner asserts that "Saulpaugh teaches of *a space facility [that is] 
provided to which a client may register or unregister to obtain notification when something is 
added to or removed from the space™ (Office Action dated January 9, 2006, page 16, lines 5- 
7, citing to Saulpaugh, column 42, lines 42-44; emphasis in original). This point is repeated 
where the Examiner recites that "Saulpaugh teaches of 'storage (both transient and 
persistent) providers are examples of services that enable clients and services to store, 
advertise, and address content"* (Office Action dated January 9, 2006, page 17, lines 16-18, 
citing Saulpaugh, column 16, lines 24-27; emphasis in original). The Examiner goes on to 
argue that Saulpaugh is "improving on a known technology of utilizing JavaSpace as a 
persistent store for messaging" (Office Action dated January 9, 2006, page 16, lines 19-20). 
The Examiner also argues that '"the API layer may also provide an interface for messages to 
communicate between objects or pass objects, such as Java objects. API's may be provided 
to discover an object repository or "space", find a particular object, claim and release an 
object, and write or take an object to or from the object repository™ (Office Action dated 
January 9, 2006, page 17, lines 11-15, citing Saulpaugh, column 11, lines 49-55; emphasis in 
original). Second, the Examiner argues that the advances in technology enable storing large 
amounts of data in small devices (Office Action dated January 9, 2006, page 16, lines 16-18). 
Third, the Examiner argues that Saulpaugh describes implementing the "'message capable 
network layer . . .from the network classes provided by the Java2 Micro Edition (J2ME) 
platform . . . for smaller footprint devices that do not have the resources for a full Java 
platform " % (Office Action dated January 9, 2006, page 17, lines 3-6, citing Saulpaugh, 
column 12, lines 30-35; emphasis in original). The Examiner continues by explaining that 
Ui ft]he distributed computing environment protocol definition does not require nor imply the 
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use of Java on a device. Nor does it preclude ft" 1 (Office Action dated January 9, 2006, page 
17, lines 8-10, citing Saulpaugh, column 15 line 57 through column 16, line 4). 

There are three problems with the Examiner's response to the Applicant's arguments. 
First, because Saulpaugh makes it clear that Jini and JavaSpaces are inadequate to his task, 
Saulpaugh teaches away from using Jini and JavaSpaces. Second, the Examiner is arguing 
from hindsight. And third, the Examiner is citing to sections of Saulpaugh that have nothing 
to do with the Applicant's arguments. 

The claims describe using Jini and JavaSpaces 

Whatever Saulpaugh does or does not teach, Saulpaugh makes it abundantly clear that 
he considers Jini and JavaSpaces inadequate for the purpose of his patent. This is made clear 
by his repeated remarks about the limitations of Jini and JavaSpaces. Examples of where 
Saulpaugh makes such remarks have been cited in the response to the Office Action dated 
July 12, 2005, and will not be repeated here. The Applicant points out that these citations are 
merely exemplary: Saulpaugh describes at length at other points about how Jini and 
JavaSpace do not provide the functionality he requires. 

Thus, whatever "space facility" Saulpaugh describes, it is definitely not implemented 
with Jini and/or JavaSpaces. But the claims explicitly recite "a JavaSpace persistent store" 
(e.g., claims 11, 14, 42, and 44). In contrast, Saulpaugh expounds at length about the 
limitations of Jini and JavaSpaces, and makes it clear that in his opinion, his "space facility" 
cannot be implemented using Jini and/or JavaSpaces. 

The Examiner's citations to Saulpaugh, column U, 16, and 42 cited above, along with 
other citations to columns 8 and 32, if they mention a "space facility" at all, only describe 
"space facilities" in the abstract. Accordingly, these sections of Saulpaugh need to be read in 
context. Given how Saulpaugh makes it clear that, in his opinion, Jini and JavaSpaces are 
inadequate to the task of implementing a "space facility", the proper interpretation of these 
sections of Saulpaugh requires reading in Saulpaugh 1 s understanding that the "space facility" 
cannot be implemented using Jini and/or JavaSpaces. This means that Saulpaugh teaches 
away from the claimed invention. 

The Examiner is reasoning from hindsight 

In responding to the Applicant's arguments, the Examiner argued that technological 
advances have made storage in small devices available. But at the time that Saulpaugh filed 
his patent application, small devices did not offer sufficient storage to support Java. This is 
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made clear by the Examiner's citation to Saulpaugh, column 4. But in that section, 
Saulpaugh was, again, indicating why Jini was incapable of providing the functionality he 
needed, showing again that Saulpaugh teaches away from Jini and/or JavaSpaces, But more 
than that, the Examiner is making a bald statement that devices today provide sufficient 
storage. Aside from the fact that the Examiner's statement is unsubstantiated, that devices 
today might provide sufficient storage does not support an obviousness rejection. In arguing 
that devices today are capable of providing the storage needed, the Examiner is arguing from 
hindsight, which is impermissible. In rejecting claims as obvious under 35 U.S.C. § 103(a), 
the Examiner is not permitted to argue based on hindsight. Since Saulpaugh makes it clear 
that devices at the time did not provide sufficient space to suit his needs, to argue that 
advances in technology made small devices with sufficient storage possible is arguing from 
hindsight. 

In addition, the Examiner has completely overlooked a central word in his citation to 
Saulpaugh: that the devices require a certain amount of "processing". In other words, storage 
space alone is not enough for small devices to provide the functionality Saulpaugh describes. 
The Examiner has not made any comment about whether it was obvious that devices would 
have sufficient processing capability. 

The Examiner cites to sections of Saulpaugh that are off point 
In citing to columns 8, 11, 12, and 16 of Saulpaugh, the Examiner points to a number 
of different topics: a gate factory, a message capable network layer, and APIs. The Applicant 
fails to understand the Examiner's reasoning in citing these sections. None of these citations 
have anything to do with how the *'space facility" might be constructed. Instead, these 
citations discuss other aspects of Saulpaugh. Because the citations have nothing to do with 
the construction of the "space facility" of Saulpaugh, these sections are without any merit. 

In particular, the Examiner cites to the end of column 15 and the start of column 16, 
where Saulpaugh describes the distributed computing environment protocol definition. The 
Applicant thinks it worth noting that Saulpaugh states that the definition does not require, 
imply, or preclude the possibility of Java on the device. The Applicant argues that this shows 
that Saulpaugh's "space facility", whatever it is, is not implemented in Java. If the device 
discussed in columns 15-16 of Saulpaugh can operate without implementing Java, then the 
"space facility" is not implemented using Jini and/or JavaSpaces. And if the device under 
can support Java or not, then that choice is for whatever other purpose the device might want 
to support Java: it has nothing to do with the implementation of the *'space facility". 
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For the foregoing reasons, reconsideration and allowance of claims 11-14, 16, 18-19, 
27-3 1 and 38-45 of the application as amended is solicited. The Examiner is encouraged to 
telephone the undersigned at (503) 222-361 3 if it appears that an interview would be helpful 
in advancing the case. 



MARGER JOHNSON & McCOLLOM, P.C 
210 SW Morrison Street, Suite 400 
Portland, OR 97204 
503-222-3613 
Customer No. 20575 
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Respectfully submitted, 



MARGER JOHNSON & McCOLLOM, P.C. 




Ariel S. Rogson 
Reg. No. 43,054 



